Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add API for yfinance #16

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Add API for yfinance #16

wants to merge 5 commits into from

Conversation

marc-at-brightnight
Copy link
Collaborator

  • Will come in handy when LLM can call the API and fetch data on behalf of the user

- Will come in handy when LLM can call the API and fetch data on behalf of the user
Copy link
Owner

@rgaveiga rgaveiga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If, on one hand, the latest PR, which eliminates that unnecessary Strategy class, is indeed one of the most significant enhancements to this lib since its inception, this PR, on the other hand, represents a significant regression. Let me clarify, the ability to retrieve market data is undoubtedly beneficial, but it should be considered as an add-on feature. It should be implemented into a separate directory, with its dedicated models.py, rather than being integrated into the core functionality of the lib. While yfinance is undeniably a very useful lib, one that I personally utilize extensively, it's worth noting, as its creator acknowledges, that it relies on the structure of Yahoo! Finance web site. If Yahoo! were to alter their website layout or even cease providing this information freely, yfinance would become obsolete. Moreover, there's another crucial aspect to consider. Another developer might submit a PR that utilizes alternative APIs (such as Interactive Brokers, Alpaca, QuantConnect, Bloomberg, etc.) to access market data. Other APIs that do not exist nowadays can be created. We need to take this into consideration when preparing the structure of the project for add-on features.

@marc-at-brightnight
Copy link
Collaborator Author

If, on one hand, the latest PR, which eliminates that unnecessary Strategy class, is indeed one of the most significant enhancements to this lib since its inception, this PR, on the other hand, represents a significant regression. Let me clarify, the ability to retrieve market data is undoubtedly beneficial, but it should be considered as an add-on feature. It should be implemented into a separate directory, with its dedicated models.py, rather than being integrated into the core functionality of the lib. While yfinance is undeniably a very useful lib, one that I personally utilize extensively, it's worth noting, as its creator acknowledges, that it relies on the structure of Yahoo! Finance web site. If Yahoo! were to alter their website layout or even cease providing this information freely, yfinance would become obsolete. Moreover, there's another crucial aspect to consider. Another developer might submit a PR that utilizes alternative APIs (such as Interactive Brokers, Alpaca, QuantConnect, Bloomberg, etc.) to access market data. Other APIs that do not exist nowadays can be created. We need to take this into consideration when preparing the structure of the project for add-on features.

So your suggestion is to make a separate directory called api/ inside optionlab/ with a yfinance.py module, with the thought being that eventually we will add more APIs?

@rgaveiga
Copy link
Owner

So your suggestion is to make a separate directory called api/ inside optionlab/ with a yfinance.py module, with the thought being that eventually we will add more APIs?

This is certainly a possibility to segregate add-on code from the core of the library. Perhaps not a directory named "api," but rather a directory with a name that more clearly suggests it contains modules providing functions for users to acquire market data for their simulations. Something akin to what I proposed for a directory containing modules implementing more advanced models (such as Heston, Merton's jump-diffusion, SABR, etc.).

@charlesverge
Copy link

Might be better to have a separate project for data retrieval and keep the prediction library standalone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants